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ABSTRACT 


Recent Internet applications, such as the World Wide Web, tie 
together a great diversity in data formats, client and server 
platforms, and communities. This has created a need for media 
feature descriptions and negotiation mechanisms in order to identify 
and reconcile the form of information to the capabilities and 
preferences of the parties involved. 


Extensible media feature identification and negotiation mechanisms 
require a common vocabulary in order to positively identify media 
features. A registration process and authority for media features is 
defined with the intent of sharing this vocabulary between 
communicating parties. In addition, a URI tree is defined to enable 
sharing of media feature definitions without registration. 


This document defines a registration procedure which uses the 
Internet Assigned Numbers Authority (IANA) as a central registry for 
the media feature vocabulary. 


Please send comments to the CONNEG working group at <ietf- 


medfree@imc.org>. Discussions of the working group are archived at 
<URL: http://www.imc.org/ietf-medfree/>. 
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1 Introduction 


Recent Internet applications, such as the World Wide Web, tie 
together a great diversity in data formats, client and server 


platforms, and communities. This has created a need for media 
feature descriptions and negotiation mechanisms in order to identi 
and reconcile the form of information to the capabilities and 
preferences of the parties involved. 


Extensible media feature identification and negotiation mechanisms 
require a common vocabulary in order to positively identify media 
features. A registration process and authority for media features 
defined with the intent of sharing this vocabulary between 

communicating parties. In addition, a URI tree is defined to enabl 


fy 


e 


sharing of media feature definitions without registration. 


This document defines a registration procedure which uses the 


Internet Assigned Numbers Authority (IANA) as a central registry for 


the media feature vocabulary. 


This document uses the terms MUST, MUST NOT, SHOULD, SHOULD NOT and 


MAY according to usage described in [8]. 
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2 Media feature tag definitions 
2.1 Media feature tag purpose 


Media feature tags represent individual and simple characteristics 
related to media capabilities or properties associated with the 
resource to which they are applied. Examples of such features are: 


the color depth of the screen on which something is to be displayed 
the type of paper available in a printer 

the support of the ‘floating 5 dimensional tables’ feature 

the fonts which are available to the recipient 

the capability to display graphical content 


+ + F F 


Each media feature tag identifies a single characteristic. Values 
associated with a specific tag must use the data type defined for 
that tag. The list of allowed data types is presented below, in 
section 2.3. 


Examples of media feature tags with values are: 


* the width of a display in pixels per centimeter represented as an 
integer value. 

* a font available to a recipient, selected from an enumerated list. 
* the version of a protocol composed of integers "i.j.k", defined as 
either a value in an enumerated list or with a defined mapping to 
make the value isomorphic to a subset of integers (e.g. i*100 + 4%*10 
+k, assuming j<=9 and k<=9). 


Further examples of media feature tags are defined in detail 
elsewhere [4]. 


Feature collections may be composed using a number of individual 
feature tags [2]. Composition of feature collections is described 
elsewhere [2]. Examples of feature collections requiring multiple 
media feature tags are: 


* the set of all fonts used by a document 
* the width and height of a display 
* the combination of color depth and resolution a display can support 


This registry presumes the availability of the MIME media type 
registry, and MIME media types MUST NOT be re-registered as media 
feature tags. Media feature tags which are currently in use by 
individual protocols or applications MAY be registered with this 
registry if they might be applied outside of their current domain. 
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The media feature tag namespace is not bound to a particular 
transport protocol or capability exchange mechanism. The registry is 
limited, however, to feature tags which express a capability or 
preference related to how content is presented. Feature tags related 
to other axes of negotiation are not appropriate for this registry. 
Capability exchange mechanisms may, of course, be used to express a 
variety of capabilities or preferences. 


2.2 Media feature tag syntax 


A media feature tag is a string consisting of one or more of the 
following US-ASCII characters: uppercase letters, lowercase letters, 
digits, colon (":"), slash ("/"), dot (".") percent ("%"), and dash 
("-"). Feature tags are case-insensitive. Dots are understood to 
potentially imply hierarchy; a feature can be subtyped by describing 
it as tree.feature.subfeature and by indicating this in the 
registration. Tags should begin with an alphabetic character. 


In ABNF [6], this may be represented as: 
Feature-tag = ALPHA *( ALPHA / DIGIT / ":" / "/" / ™y™ / "-" /"ġ%™" ) 


Registrants should take care to avoid creating tags which might 
conflict with the creation of new registration trees; in general this 
means avoiding tags which begin with an alphabetic character followed 
by a dot. The current registration trees are described in section 3 
below. 


2.3 Media feature tag values 


The registry will initially support the use of the following data 
types as tag values: 


- signed integers 

- rational numbers 

- tokens, with equality relationship 

- tokens, with defined ordering relationship 

- strings, with standard (octet-by-octet) equality relationship 
- strings, with defined equality and/or comparison relationship 


"Token" here means the token data type as defined by [7], which may 
be summarized as: 
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token = 1*<any CHAR except CTLs or tspecials> 
tspecials = men / ue eu / wen / wou / wan 

7: area! f pier 7. Ean / nAn vi <> 

/ " /" / " [" / ") " / wow / wow 

f. "gT J ER f SP / HT 


At the time of registration, each tag must be associated with a 
single data type. If that data type implies a defined comparison or 
an ordering, the registrant must define the ordering or comparison. 
For ordered tokens, this may be by full enumeration of the tokens and 
their order or by reference to an ordering mechanism. For defined 
comparisons, a full description of the rules for comparison must be 
provided or included by reference. 


Media feature tags related to spatial or temporal characteristics 
must be registered with a single canonical unit. It is strongly 
preferred that units be in the SI system; where current practice has 
defined units in other systems (such as pixels per inch), a 
conversion method to SI units must be provided. Conversion methods 
should include a defined rounding practice. 


2.4 ASN.1 identifiers for media feature tags 


Certain protocols use ASN.1 identifiers rather than human-readable 
representations for capability exchange. In order to allow both 
systems to interoperate, registrants may provide an ASN.1 identifier 
or ask that IANA assign an ASN.1 identifier during registration. 
These identifiers are not required for registration, but may provide 
assistance to those building gateways or other cross-protocol 
systems. Note that ASN.1 identifiers assigned by IANA will be 
treated as tokens, not as elements from which sub-delegated 
identifiers may be created or derived. 


3 Media feature tag registration 


Media feature tags can be registered in several different 
registration trees, with different requirements as discussed below. 
The vocabulary for these requirements is taken from [5]. In general, 
a feature tag registration proposal is circulated and reviewed in a 
fashion appropriate to the tree involved. The feature tag is then 
registered if the proposal is accepted. 


Review of a feature tag in the URI tree is not required. 
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3.1 Registration trees 


The following subsections define registration "trees", distinguished 
by the use of faceted names (e.g., names of the form "tree.feature- 
name"). 


3.1.1 IETF tree 


The IETF tree is intended for media feature tags of general interest 
to the Internet Community, and proposals for these tags must meet the 
"IETF Consensus" policies described in [5]. 


Registration in the IETF tree requires approval by the IESG and 
publication of the feature tag specification as an RFC. Submissions 
for feature tag registration in the IETF tree can originate in any WG 
of the IETF or as an individual submission to the IESG. 


Feature tags in the IETF tree normally have names that are not 
explicitly faceted, i.e., do not contain period (".", full stop) 
characters. 


3.1.2 Global tree 


Tags in the global tree will be distinguished by the leading facet 
"g.". An organization may propose either a designation indicative of 
the feature, (e.g., "g.blinktags") or a faceted designation including 
the organization name (e.g., "g.organization.blinktags"). 
Organizations which have registered media types under the MIME vendor 
tree should use the same organizational name for media feature tags 
if they propose a faceted designation. The acceptance of the proposed 
designation is at the discretion of the IANA. If the IANA believes 
that a designation needs clarification it may request a new proposal 
from the proposing organization or otherwise coordinate the 
development of an appropriate designation. 


Registrations of feature tags in the global tree must meet the 
"Expert Review" policies described in [5]. In this case, a 
designated area expert will review the proposed tag, consulting with 
the members of a related mailing list. A registration may be 
proposed for the global tree by anyone who has the need to allow for 
communication on a particular capability or preference. 


3.1.3 URI tree 


A feature tag may be defined as a URI using the restricted character 
set defined above. Feature tags in the URI tree are identified by the 
leading facet "u.". The leading facet u. is followed by a URI [9] 
which conforms to the character limitations specified in this 
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document. The author of the URI is assumed to be registration 
authority regarding features defined and described by the content of 
the URI. These tags are considered unregistered for the purpose of 


this document. 
3.1.4 Additional registration trees 


From time to time and as required by the community, the IANA may, 
with the advice and consent of the IESG, create new top-level 
registration trees. These trees may be created for external 
registration and management by (for example) well-known permanent 
bodies, such as scientific societies for media feature types specific 
to the sciences they cover. Establishment of these new trees will be 
announced through RFC publication approved by the IESG. 


3.2 Location of registered feature tag list 


Feature tag registrations will be posted in the anonymous FTP 
directory: "ftp://ftp.isi.edu/in-notes/iana/assignments/media-— 
feature-tags/" and all registered feature tags will be listed in the 
periodically issued "Assigned Numbers" RFC [currently STD 2, RFC- 
1700]. The feature tag description and other supporting material may 
also be published as an Informational RFC by sending it to "rfc- 
editor@rfc-editor.org". 


3.3 IANA procedures for registering feature tags 
The IANA will only register feature tags in the IETF tree in response 
to a communication from the IESG stating that a given registration 
has been approved. 
Global tags will be registered by the IANA after review by a 
designated expert. That review will serve to ensure that the tag 
meets the technical requirements of this specification. 


3.4 Registration template 


To: media-feature-tags@apps.ietf.org (Media feature tags mailing list) 
Subject: Registration of media feature tag XXXX 


| Instructions are preceded by ‘|’. Some fields are optional. 
Media feature tag name: 
ASN.1 identifier associated with feature tag: [optional] 


| To have IANA assign an ASN.1 identifier, 
| use the value "New assignment by IANA" here. 
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Summary of the media feature indicated by this feature tag: 


Include a short (no longer than 4 lines) description or summary 


Examples: 
| ‘Use of the xyzzy feature is indicated by ...’ 
| ‘Support of color display is indicated by ...’ 


‘Number of colors in a palette which can be defined 
Values appropriate for use with this feature tag: 


[ ] 1. The feature tag is Boolean and may have values of 
TRUE or FALSE. A value of TRUE indicates an available 
capability. A value of FALSE indicates the capability 
is not available. 


If you wish to indicate two mutually exclusive possibilities 
that cannot be expressed as the availability or lack of a 
| capability, use a two-token list, rather than a Boolean value. 


[ ] 2. The feature has an associated numeric or enumerated value. 
For case 2: Indicate the data type of the value: 


2a. Signed Integer 

2b. Rational number 

2c. Token (equality relationship) 
2d. Token (ordered) 

2e. String (equality relationship) 
2f. String (defined comparison) 


mman mamn a 
AEN SEE E E Pa SEa A ee A 


| IMPORTANT: You may only chose one of the above data types. 


(Only for case 2) Detailed description of the feature value meaning, 
and of the format and meaning of the feature tag values for the 
alternative results. 


If you have selected 2d you must provide the ordering mechanism 
or a full and ordered enumeration of possible values. If you 
have selected 2f, you must provide a definition of the comparison. 
Definitions by included reference must be to stable and readily 
available specifications: 


If the number of alternative results is small, you may 


enumerate the identifiers of the different results and describe 
their meaning. 


| 
| 
| 
| 
| If there is a limited useful numeric range of result (2b, 2c), 
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indicate the range. 


The identifiers of the alternative results could also be 
described by referring to another IANA registry, for example 
| the paper sizes enumerated by the Printer MIB. 
The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 
[optional] 


| For applications, also specify the number of the first version 
| which will use the tag, if applicable. 


Examples of typical use: [optional] 
Related standards or documents: [optional] 


Considerations particular to use in individual applications, 
protocols, services, or negotiation mechanisms: [optional] 


Interoperability considerations: [optional] 
Security considerations: 


Privacy concerns, related to exposure of personal information: 


Denial of service concerns related to consequences of specifying 
incorrect values: 


Other: 

Additional information: [optional] 
Keywords: [optional] 
Related feature tags: [optional] 
Related media types or data formats: [optional] 
Related markup tags: [optional] 


Name(s) & email address(es) of person(s) to contact for 
further information: 


Intended usage: 


| one of COMMON, LIMITED USE or OBSOLETE 
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Author/Change controller: 
Requested IANA publication delay: [optional] 
| A delay may only be requested for final placement in the global 
| or IETF trees, with a maximum of two months. Organizations 
| requesting a registration with a publication delay should note 
| that this delays only the official publication of the tag 
and does not prevent information on it from being disseminated 
by the members of the relevant mailing list. 


Other information: [optional] 


| Any other information that the author deems interesting may be 
| added here. 


4 Security Considerations 


Negotiation mechanisms reveal information about one party to other 


parties. This may raise privacy concerns, and may allow a malicious 
party to make better guesses about the presence of specific security 
holes. 
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8 Full Copyright Statement 
Copyright (C) The Internet Society (1999). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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